Remote firing system

ABSTRACT

A remote firing system for remotely detonating explosive charges includes features that provide safety and efficiency improvements. These features include safety communication among multiple remote devices and multiple controller devices, a polling functionality permitting rapid deployment of system devices, electronic key systems, and programmable remote devices for easy replacement of failing remote devices.

CROSS-REFERENCE TO RELATED APPLICATION

This application claims the benefit of U.S. Provisional Application No. 60/537,153, filed Jan. 16, 2004, which is expressly incorporated herein by reference.

FIELD OF THE INVENTION

This invention relates generally to remote firing systems and, more particularly, to safety communication of remote firing systems.

BACKGROUND OF THE INVENTION

Blasting machines are devices used to trigger detonators. A detonator, in turn, triggers a main charge explosive. The use of blasting machines created a significantly safer and more efficient environment for the detonation of explosives in mining, construction, and military applications. Blasting machines replace the traditional lit fuse method of initiating explosives. Blasting machines typically use a lead line comprised of a pair of copper wires or a shock tube. The use of a blasting machine increases safety by allowing a greater standoff between the operator and the explosive charge, a shorter lag time between the initiation of the firing sequence and the actual detonation of the explosive, as well as a reduction in the number of accidental ignition sources that could trigger a blast unintentionally. Blasting machines make detonation of explosives more efficient by creating a more reliable and consistent source of initiation, reducing the amount and cost of materials used, as well as allowing for faster setup thereby reducing overall manpower time as compared to traditional fuses.

FIG. 1A depicts a plan view of an open pit mine 100. Three separate groups of explosives 118 A-C, known as shots, are situated in various locations throughout the mine. Each shot 118 A-C is tethered to a blasting machine (not pictured) and operator 116 A-C by a lead line 126 A-C. This allows the operator 116 A-C to initiate a blasting sequence, transmitting a signal with a blasting machine through the lead line 126 A-C to the detonators in the shot 118 A-C.

A danger area 124 A-C is associated with loose rock, known as fly rock, which can be thrown to great distances by the explosive force released upon detonation of the shot 118 A-C. To ensure safety, the blasting machine and operator 116 A-C must be located outside of the danger area 124 A-C created by the explosion. Similarly, vehicles 114 A-C and other mine employees 112 A-B must also be located outside of the danger area 124 A-C of each shot 118 A-C. Mine personnel (not shown), known as spotters, guard areas of ingress that cannot be observed by the blasting machine operator, preventing other mineworkers or equipment from entering the danger area 124A-C during a shot. As can be appreciated by FIG. 1A, overlapping danger areas 124 A-C from each shot 118 A-C can create significant portions of a mine that pose a risk to both vehicles 114 A-C and mine personnel 112 A-B when blasting ensues. To ensure that a blasting machine and operator 116 A-C are outside of a danger area 124 A-C, long lengths of lead line 126 A-C are used, typically between 300 and 600 meters.

It is desirable to minimize the amount of time a mine is evacuated (downtime) because of the great expense associated with a non-producing mine. Shooting multiple shots close in time minimizes downtime. Typically, separate shots 118 A-C will use separate blasting machines and operators 116 A-C to minimize downtime and maximize efficiency. FIG. 1A further illustrates the typical one to one relationship of shot 118 A-C to blasting machine and operator 116 A-C. For each shot 118 A-C, a separate blasting machine and operator 116 A-C are used to initiate a signal on a dedicated lead line 126 A-C.

FIG. 1B depicts a cross-sectional view of a subterranean mine 150. As in surface mining, blasting machines and lead lines can be used to detonate explosives in a subterranean mine. Shots are placed in headings 156 A-D of working shafts 154 A-D. These working shafts 154 A-D connect to the main shaft 152. The main shaft 152 leads to the surface. Due to the dangers of cave-ins for subterranean mining, entire mines are generally shut down and evacuated prior to detonation of explosives. This requires evacuation of both the operator 116 J and mine personnel 112 C to the surface; some equipment 158 can be removed as well. To ensure that all mine personnel are outside of the mine, mining companies frequently employ safety interlock devices such as a tag board. Subterranean mines can have multiple headings 156 A-D, each of which may, or may not, have a shot placed in it. As in the surface mining example (FIG. 1A) this adds complexity to firing shots, as each individual shot requires a distinct lead line and blasting machine. Ideally, the operator would FIRE the shot from the surface to avoid a possible cave-in. However, in large mines this might require unreasonably long or expensive lead lines. Thus, shorter lead lines can be used, forcing the operator to FIRE the shot underground in a less safe environment.

More recently, the introduction of a remote control blasting machine has further increased the safety and efficiency of blasting. A remote control blasting machine essentially separates a traditional blasting machine into two components, a remote device 182 and a controller device 184. FIG. 1C depicts a remote control blasting machine system 180. An operator 196 manipulates a controller device 184, transmitting a signal 186 to a remote device 182. The remote device 182 is coupled to a shortened lead line 198. The shortened lead line 198 is coupled to a detonator line 194 which is coupled to a detonator 192 placed in a main explosive charge 188. The explosive charge 188 is capped with stemming 190. Stemming 190 consists of gravel and rock chips and is used to focus the energy of the explosion into fracturing new rock rather than just exploding out of the top of the hole in which the explosive is placed. FIG. 1C further illustrates a communication that includes commands transmitted from a controller device 184 and received by a remote device 182 (illustrated by an arrow 186). The remote device 182 affirms a received signal, but provides no additional information beyond this affirmation.

An additional safety and efficiency concern of remote control blasting machines is associated with deployment of the remote device 182. Information sent using radio frequencies is the typical method for communication between a controller device 184 and a remote device 182. Topographical features or atmospheric conditions can attenuate effective radio frequency communication range. This attenuation can result in ineffective placement of a remote device 182 or controller device 184 and create uncertainty in a blasting sequence, thereby reducing safety and efficiency. If weather changes or the movement of equipment at a mine disrupt communication, a shot may not fire, leaving an unexpected live explosive charge in the field where workers will be returning. This is a significant disadvantage associated with remote control blasting machines and is especially troublesome in subterranean mines 150 where electromagnetic attenuation is a more significant problem than in surface mining 100.

SUMMARY OF THE INVENTION

In accordance with this invention, a remote firing system, a controller device, a remote device, and a method for remotely detonating explosives is provided. The system form of the invention includes a remote firing system that comprises a set of remote devices. Each remote device is capable of communicating a safety data structure that contains a system identifier for identifying the remote firing system from other remote firing systems and a device identifier for identifying a remote device from other remote devices. The remote firing system further includes a controller device for causing the set of remote devices to trigger detonators. The controller device is capable of selecting a subset of the set of remote devices for triggering detonators and further being capable of communicating the safety data structure that contains a system identifier for identifying the remote firing system from other remote firing systems and device identifiers for identifying the subset of remote devices to control.

In accordance with further aspects of this invention, a device form of the invention includes a controller device that includes a set of selection and information panels that correspond with a set of remote devices. A subset of selection and information panels is selectable to cause a corresponding subset of remote devices to be selected for detonating explosives. The controller device further includes a communication module for transmitting and receiving safety communication. The communication module is capable of communicating with the subset of remote devices to indicate their selection for detonating explosives by the controller device.

In accordance with further aspects of this invention, a device form of the invention includes a remote device that includes a communication module for transmitting and receiving a safety data structure that contains a system identifier for identifying a remote firing system that comprises the remote device and a device identifier for identifying the remote device. The remote device further includes a switch for selecting either shock-tube detonator initiation or electric detonator initiation.

In accordance with further aspects of this invention, a method form of the invention includes a method for remotely detonating explosives. The method includes selecting a subset of a set of selection and information panels on a controller device to cause a corresponding subset of remote devices to be selected for detonating explosives. The method further includes issuing an arming command by the controller device to the subset of remote devices to cause the subset of remote devices to prepare for detonation. The method yet further includes issuing a firing command by the controller device to the subset of remote devices by simultaneously selecting dual fire switches together on the controller device to cause the subset of remote devices to detonate explosives.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing aspects and many of the attendant advantages of this invention will become more readily appreciated as the same become better understood by reference to the following detailed description, when taken in conjunction with the accompanying drawings, wherein:

FIG. 1A is a pictorial diagram showing a plan view of an open pit surface mine, wherein conventional blasting techniques are employed;

FIG. 1B is a pictorial diagram showing a cross-sectional illustration of a subterranean mining operation;

FIG. 1C is a pictorial diagram illustrating a remote control blasting machine with conventional communication capability;

FIG. 2A is a pictorial diagram illustrating a remote firing system using safety communication according to one embodiment of the present invention;

FIG. 2B is a pictorial diagram illustrating multiple remote firing systems using safety communication between multiple remote devices and a single controller device in each remote firing system, according to one embodiment of the present invention;

FIG. 3A is a pictorial diagram of a controller device user interface, in accordance with one embodiment of the present invention;

FIG. 3B is a pictorial diagram illustrating a remote device user interface, in accordance with one embodiment of the present invention;

FIG. 4A is a block diagram illustrating various inputs and outputs for both the controller device and the remote device of a remote firing system, in accordance with one embodiment of the present invention;

FIG. 4B is a block diagram showing various inputs, outputs, and internal control modules for a controller device, in accordance with one embodiment of the present invention;

FIG. 4C is a block diagram showing various inputs, outputs, and internal control modules for a remote device, in accordance with one embodiment of the present invention;

FIGS. 5A-5O are process diagrams illustrating an exemplary method formed in accordance with this invention for remotely detonating explosives by employing a remote firing system.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

As discussed hereinbefore, blasting machines have improved the safety and efficiency of detonating explosive charges in mining, construction, and military applications. Both typical lead-line blasting machines (tethered systems) and remote control blasting machines have provided significant increases in safety and efficiency over prior techniques. However, still greater increases in efficiency and safety can be achieved through various embodiments of the present invention.

FIG. 2A illustrates the constituent parts of a remote firing system 200 that include a remote device 208 and a controller device 202 that interoperate to provide safety communication in accordance with one embodiment of the present invention. The inputs 210 may include for example, user commands or safety interlock device signals. The remote device 208 is coupled to a lead line 212 to transmit a signal that initiates a detonator.

The term safety communication used hereinabove and hereinbelow means any suitable communication occurring between a remote device and a controller device that indicates that interoperation is safe. One suitable safety communication occurs when a safety data structure is transmitted from a first piece of equipment and received at a second piece of equipment and transmitted from the second piece of equipment and received by the first piece of equipment. In one embodiment of the present invention a safety data structure containing blasting information can be transmitted from the controller device 202 and received by the remote device 208, and another safety data structure containing blasting information can be transmitted from the remote device 208 and received by the controller device 202. Blasting information contained within the safety data structure includes the battery condition of a device; armed or ready status of a device; error detection codes; system, device, index identification; and timing information among other pieces of information. These pieces of information, any of which could form part of a safety data structure, are not exhaustive or exclusive and additional suitable pieces of blasting information can be contained by the safety data structure.

FIG. 2B illustrates a remote firing system comprising multiple remote devices interoperating with a controller device using safety communication. One embodiment of the present invention includes the use of an electronic key. An electronic key is a device that provides the means of gaining or preventing control of another device electronically, mechano-electronically, opto-electronically, or some combination thereof. When an electronic key is coupled to a piece of equipment in a remote firing system, information contained on the electronic key is preferably electronically accessible by the piece of equipment. This information provides various suitable identifications, such as, whether the electronic key permits access to a controller device or a remote device; programming level access to a remote device; identification of a unique remote firing system; and an index identifying the last programming event for that particular electronic key. The electronic keys 230, 232, 246, 248, and 250 provide one or more suitable pieces of identification information. For example, three pieces of suitable identification information delimited by colons: DEVICE:SYSTEM:INDEX. Preceding the first delimiter is the device identifier. After the first and before the second delimiter is the system identifier. After the second delimiter is the incremented index. For example, a string of 0:A:T1 represents a controller device identified as 0, on remote firing system A, last programmed with index T1.

The device identifier, coded on an electronic key, increases the safety of operating multiple remote devices through a single controller device. In one embodiment of the present invention, the controller device 226 or 228 is used preferably to operate one to eight remote devices, although less or more remote devices are possible. Preferably, remote devices are non-operational when a controller device electronic key is coupled to the remote devices. Further, the controller device operates preferably in a programming mode when a remote device electronic key is coupled to the controller device if the controller is in key programming mode. When a remote device is coupled to a compatible remote device electronic key or when a controller device is coupled to a compatible controller device electronic key, the devices preferably operate normally. As illustrated in FIG. 2B, the controller electronic keys 230 and 232 include the device identifier 0 and identify controller devices 226 and 228. The remote electronic keys 246, 248, and 250 include the identifiers X and Z.

The remote firing system identifier serves to increase the safety of concurrent operation of multiple remote firing systems 220. Each remote firing system 222 and 224 is designated by a unique identifier such as A and B. (See electronic keys 230 and 232.) In one embodiment of the present invention, the system identifier includes the serial number of the controller device. Remote devices coupled to remote device electronic keys with suitable system identifiers and indexed identifiers (discussed below) function normally. Remote devices coupled to remote device electronic keys preferably discard a transmission received from a controller device on a different system with different system identifiers. In FIG. 2B, the safety communication of system A (illustrated by arrows 252, 234, 236, and 254) occurs among the system A controller and compatible remote devices, and system B safety communication (illustrated by arrows 238 and 256) occurs among the system B controller and compatible remote devices. Further, the controller device preferably operates with a controller device electronic key containing the same system identifier as stored internally on the controller device.

The indexed identifier information stored on an electronic key represents the most recent programming event of the electronic key. Each time an electronic key is reprogrammed on a controller device, the identifier is indexed and updated on the electronic key and stored internally on the controller device. This prevents more than one remote firing system device electronic key from carrying identifier information that is identical (same device identifier, same system identifier, and same indexed identifier) as another electronic key. For example, if a first electronic key is programmed to 4:A:T1, an attempt to program a second electronic key with the same identifiers will result in the index identifier being incremented. The identification information that would be stored on the second electronic key is 4:A:T2. Any suitable incrementing process can be used, such as time stamping. The electronic key with the most recent indexed identifier preferably allows a remote device to function while the electronic key with the older indexed identifier will not allow the device to function, despite both keys otherwise identifying the same device and system identifiers.

Electronic keys with the same device identifier and indexed identifier are possible, but preferably exist on different systems, by design, maintaining the robust nature of the unique electronic key scheme. For example, if the first electronic key is 4:A:T2, a second key, with an identical device identifier and indexed identifier, 4 and T2, preferably be programmed on system B (more precisely, the system identifier can be programmed on any system other than system A) yielding 4:B:T2. If the second key were programmed with a device identifier 4 and a system identifier A, the indexed identifier would be incremented yielding 4:A:T3. Essentially, each electronic key contains a unique set of identifiers distinguishing a controller or remote device, a remote firing system, and the most recent set of programming. This creates an additional level of safety by creating unique electronic keys and preventing multiple, unintended detonations that could otherwise result if duplicate electronic keys were present in a remote firing system.

In one embodiment of the present invention, electronic key identification information is transmitted as a component of the safety data structure for a transmission by a piece of remote firing system equipment. A received safety data structure is parsed and the extracted identification information is compared to the information stored on an electronic key coupled to the receiving piece of equipment. For example, while each remote device 240, 242, and 244 in FIG. 2B actually receives transmissions from the controller devices 226 and 228, the arrows 234, 236, and 238 indicate selective data flow among controller devices and remote devices containing electronic keys with suitable system identifiers. The arrows 234 and 236 represent data transmission from controller device 226 with a system identifier A and the indexed identifier T1. Arrow 238 represents data transmission by controller device 228 with a system identifier B and index T1.

The transmission from controller device 226, if received by the remote device 242, is preferably discarded by remote device 242 because the system identifier is not compatible. This same transmission from controller device 226, if received by the remote devices 240 and 244, is accepted because the system and indexed identifiers are compatible. The transmission from controller device 228 is preferably accepted by remote device 242, while preferably being discarded by remote devices 240 and 244. Transmissions from the remote devices 240, 242, and 244 will preferably be discarded by controller devices 226 and 228 with uncompatible system identifiers. To recap, unless the system and indexed identifiers on the electronic keys coupled to both a controller device and one or more remote devices are compatible, the controller and remote devices preferably discard a received transmission. Preferably remote devices discard transmissions that do not identify as originating from a controller device. This allows the operator to control, with a single controller device, multiple uniquely identified remote devices. Multiple remote firing systems can be deployed contemporaneously 220 because they are unlikely to conflict with one another due to different system identifiers.

In one embodiment of the present invention, the remote devices of the firing system can be semi-permanently assigned a device identity as an alternative to assuming the identity associated with the identification information stored on a coupled electronic key. This semi-permanent programming causes the remote device to function normally preferably with remote device electronic keys having a specified device identifier that suitably relates to the semi-permanently programmed device identifier stored internally on the remote device. Additional safety results from semi-permanent programming of remote devices for particular applications where the remote device is not frequently moved. As an example of semi-permanent programming, if electronic key 4:A:T2 is coupled to an unprogrammed remote device, the remote device will assume the identity 4:A:T2 and discard received transmissions that do not include compatible identifiers. The remote device preferably returns to a non-operational state when the electronic key is removed. If this same unprogrammed remote device is then semi-permanently programmed as system device number 6, the electronic key 4:A:T2 will not be recognized as valid when coupled to the remote device because the key has a system device identifier number 4 and not number 6. The semi-permanently programmed remote device will however preferably function normally (assuming a received transmission includes suitable identifiers) with any of the following electronic keys: 6:A:T1, 6:A:T5, 6:C:T1, 6:S:T9, for example. This is because they all have the same device identifier as the semi-permanently programmed system device identifier stored internally on the remote device. The number 6 identifier programmed is preferably nonvolatile and persists until the device is reset to an unprogrammed state or is semi-permanently programmed to a different device identity. In one embodiment of the present invention, semi-permanent system device identity programming is achieved preferably through the use of a master electronic key.

FIG. 3A illustrates an exemplary front panel for a controller device user interface 300 in accordance with one embodiment of the present invention. Any suitable number of remote devices are controllable from the controller device user interface 300. One suitable number of remote devices, in accordance with one embodiment of the present invention, is eight remote devices. The left portion of the controller device user interface 300 encompasses the selection and information panel 304 A-H for eight remote devices. Each remote device panel 304 A-H includes a membrane switch 306 A-H that allows selection or deselection of the associated remote device. Further, each remote device panel 304 A-H includes labeling and an LED indicator for the READY state 308, ARMED state 310, battery condition 312, and selected state 314 of the associated remote device.

The right portion of the controller device user interface 300 includes a controller device interface, an informational interface, and a user input section interface. The controller device interface includes an external antenna connection port 316, an electronic key interface 318, and a programming port 320. The informational interface includes the controller device battery status panel 322, including labeling and an LED indicator for slow charge 324, fast charge 326, 20% remaining battery capacity 328, 40% remaining battery capacity 330, 60% remaining battery capacity 332, 80% remaining battery capacity 334, and 100% remaining battery capacity 336. These percentages of remaining battery capacity are arbitrarily selected and other percentages, or different styles of display, can be substituted in other embodiments without departing materially from the present invention.

The informational interface includes a panel 338 containing labeling and indicator LEDs for the device power 340, electronic key status 342, device transmitting 344, and device receiving 346.

The user input selection interface comprises a panel 348 for placing a controller device in the ON state, the panel 348 including labeling and a membrane switch 350. The user input selection interface further comprises a panel 352 for placing a controller device in the OFF state, the panel 352 including labeling and a membrane switch 354. The user input selection interface further comprises a panel 356 for selecting a status query operation with a membrane switch 360, the panel 356 including labeling and an LED indicator 358.

The user input selection interface further comprises a panel 362 for placing the controller device battery status panel 322 in an ON or OFF state by cycling a membrane switch 366, the panel 362 including labeling and an LED indicator 364. The user input selection interface further comprises a panel 368 for selecting an ARM command operation with a membrane switch 372, the panel 368 including labeling and an LED indicator 370. The user input selection interface further comprises a panel 374 for selecting a DISARM command operation with a membrane switch 378, the panel 374 including labeling and an LED indicator 376. The user input selection interface further comprises dual panels 380 and 386 for selecting a FIRE command operation with dual membrane switches 384 and 390, the panels 380 and 386 including labeling and LED indicators 382 and 388.

Combinations of the aforementioned LED indicators can be used to indicate device conditions. One example of this feature is flashing of all LED's when the device is placed in the ON state, indicating the initiation of a self-testing operation. Other suitable combinations are possible.

FIG. 3B illustrates an exemplary front panel for a remote device user interface 390. The remote device user interface 390 includes indicator panels 392 and 398 for selection of a method for initiating a detonation. The methods include shock-tube detonator initiation or electric detonator initiation, among others. The shock-tube detonator initiation panel 392 includes labeling and LED indicators 394 and 396 for READY and ARMED status. The electric detonator initiation panel 398 includes labeling and LED indicators 402 and 400 for READY and ARMED status. A switch 404 selects an initiation method panel 392 or 398, and, in accordance with one embodiment of the present invention, is a mechanical toggle switch. The remote device user interface 390 further includes a remote device battery status panel 406. The panel 406 includes a switch 408, for activating a battery status display 410 such as a digital voltmeter for example, and in accordance with one embodiment of the present invention, is a mechanical momentary push button switch. Other types of suitable switches and battery status displays can be used. A panel 412, for placing the remote device in an ON or OFF state, comprising a remote device power switch 414, labeling and an LED indicator 416 is included on the remote device user interface 390. The remote device user interface 390 further comprises a battery charger panel 418 and an electronic key panel 426. The battery charger panel 418 includes labeling and an indicator LED 420 for indicating connectivity to a battery charger. Two additional indicator LEDs 422 and 424 and labeling, indicating slow and fast charging rates, are included on the battery charger panel 418. The electronic key panel 426 includes a connection port 428, to couple an electronic key; three LED indicators 430, 436, and 432; and labeling to indicate remote device transmission, electronic key status, and remote device receiving in accordance with the safety communication ability of various embodiments of the present invention. The remote device user interface 390 further includes a port 438 for connecting an external antenna, and a programming port 440.

The remote device user interface 390 further includes a connection port 442 for connection of a lead line to the initiation circuitry. This port is located on the left sidewall of the remote device and comprises of two female banana plug connectors and two binding posts. Other suitable connectors or suitable locations for the connection port 442 can be used.

In one embodiment of the present invention, combinations of the aforementioned remote device user interface 390 LED indicators are used to indicate various device conditions. One example is the slow charge LED 422 being on and fast charge LED 424 being off to indicate a fully charged battery. Other combinations are possible.

FIG. 4A is a block diagram of a remote firing system. A controller device 450 and at least one remote device 452 use safety communication to communicate via a transmission medium 454. Signals from an interlock device 456, user inputs 458, information stored on an electronic key 460, and signals received via the transmission medium 454 are processed by the controller device 450. Similarly, information stored on an electronic key 462, user inputs 464, and signals received from the transmission medium 454 are processed by the remote device 452. Additionally, the remote device 452 produces a signal for initiating explosives. This signal is transmitted from the remote device, though a lead line 466 and a chain of components 468, terminating in a main explosive charge (not shown).

FIG. 4B is a block diagram of internal functional modules, inputs, and outputs for a controller device 450. The internal functional modules include an electronic key module 502; a programming port module 504; a self-test module 506; a battery status module 508; a controller device user interface module 510; a timer module 512; a remote device selection module 514; a controller device mode module 516; a controller device command module 518; and a communications module 520 for transmitting and receiving safety communication. Inputs to the controller device can be received as information stored on an electronic key 522 coupled to the controller device key module 502; information from an interlock device 524 coupled to the programming port module 504; information from user inputs 526 selecting remote devices through the remote device selection module 514, controller device operating mode through the controller device controller device mode module 516, and commands through the command module 518. Safety communication is preferably achieved by transmitting and receiving a safety data structure through an external antenna 528 coupled to the communications module 520. Other devices, including but not limited to radio repeaters and leaky feeder systems, can be connected in place, or in addition to, of the external antenna 528 without departing materially from the present invention.

Preferably, the electronic key module 502 serves as a coupling interface between the controller device 450 and the external electronic key 522. Information stored on the electronic key 522 is read into the controller device's internal memory (not shown) for processing by the controller device 450, or the controller device 450 can write information onto the electronic key 522 through the electronic key module 502.

Preferably, the programming port module 504 serves as a coupling interface between the controller device 450 and an external programming device (not shown), such as a digital computer, or the interlock device 524. The external programming device (not shown) may allow, for example, information stored in certain memory locations to be read out of the controller device 450; information to be written into certain memory locations on the controller device 450; or modification of internal controller device settings; among others. Many operations can be conducted through the programming port module 504. The programming port module 504 can be implemented using a 14-pin DIN type connector or other suitable connectors, designating various conductors for functionality such as battery charger contacts, external interlock device 524 input contacts, programming function contacts, and contacts for additional future functionality, among others.

Preferably, the self-test module 506 tests the internal circuitry and functionality of the controller device 450 for faults. The self-test module 506 indicates component failures by flashing indicator LEDs on the controller device user interface panel 300, as discussed previously. Other suitable methods of indicating self-test results can be used.

Preferably, the battery status module 508 displays the status and condition of a battery (not shown) in the controller device 450. The battery status module 508 may include a battery capacity display, such as a gas-gauge style digital display; battery condition indicators, such as the previously discussed flashing indicator LED's on the controller device user interface panel 300; and recharge rate indicator LEDs, among others. Other suitable displays and indicators can be used.

The timer module 512 can be implemented mechanically, with discrete electronics, with software, or by some combinations thereof. Preferably, the timer module 512 is used for controller device features requiring elapsed time information. For example, the timer module 512 is a software implemented, countdown timer triggering the execution of a DISARM command if the controller device 450 has transmitted an ARM command and has not transmitted a FIRE command within a specified time period.

Preferably, the communications module 520 serves to enable safety communication between the controller device 450 and other system devices through a transmission medium. Preferably, the communications module 520 includes a 5-watt maximum power radio transceiver for transmission and reception of radio frequency signals in the kHz to MHz range. Any suitable power or frequency range can be used for the transceiver without departing materially from the present invention. Further, other suitable methods of communication can be used.

Preferably, the controller device user interface module 510 includes all user input into the controller device 450 not included in the remote device selection module 514, controller device mode module 516, or controller device command module 518. This module includes functions such as turning a battery meter ON or OFF, among others.

Preferably, the remote device selection module 514 serves as an interface for the user allowing specific remote devices to be either selected or de-selected by the user. Preferably, multiple remote devices can be contemporaneously selected and operated from a single controller device.

Preferably, the controller device command module 518 serves as the user interface to selectively initiate command signals. The available commands may include ARM, FIRE, DISARM, and STATUS (querying the status of remote devices), among others. Other suitable commands can be used without materially departing from the present invention.

Preferably, the controller device mode module 516 serves as the user interface for selecting the operating mode of the controller device 450. The controller device mode module 516 may include NORMAL (signifying normal operation mode), PROGRAMMING (signifying programming mode), and QUERY (signifying safety communication query mode, such as the SAFETY POLL™ query facility offered by Rothenbuhler Engineering Co.), among others. The NORMAL mode is preferably the default mode and is used for detonating explosives. The PROGRAMMING mode preferably allows the controller device 450 to function as a programming device for programming electronic keys. Or other programmable options. The QUERY mode is preferably used to automatically test safety communication between the controller device 450 and selected remote devices (not shown.) Additional suitable modes, or suitable modification of the listed modes, can be included into the controller device mode module 516.

FIG. 4C is a block diagram of the internal functional modules, inputs, and outputs for a remote device 452. The internal functional modules include modules such as an electronic key module 532; a remote device user interface module 534; a self-test module 536; a programming port module 538; a battery status module 540; a timer module 542; a communications module 544; a remote device output mode module 546; and a remote device operating mode module 548; among others. Inputs to the remote device 452 include information contained on an electronic key 550 coupled to the electronic key module 532. Additional information can be received from user inputs 552 for selecting an output mode (through the output mode module 546), and for selecting an operating mode (through the operating mode module 548.) Additionally, safety communication can be received or transmitted by an external antenna 554 coupled to the communications module 544. As previously discussed, suitable alternatives can be used in place of an external antenna. A signal initiating a shot is output to a chain of devices 556 terminating in a main explosive charge (not shown) as will be appreciated by one skilled in the art.

Preferably, the electronic key module 532 serves as a coupling interface between the remote device 452 and an electronic key 550. Further, information stored on the electronic key 550 can be read into the remote device's internal memory (not shown) for processing by the remote device 452 through the electronic key module 532.

Preferably, the programming port module 538 serves as a coupling interface between the remote device 452 and an external programming device (not shown), for example a digital computer. The external programming device may allow, for example, information stored in certain memory locations to be read out of the remote device 452; information to be written into certain memory locations on the remote device 452; or modification of internal remote device settings; among others. Many other suitable operations can be conducted through the programming port module 538. The programming port module 538 can be implemented using a 14-pin DIN type connector or other suitable connectors, designating various conductors for functionality such as battery charger contacts, programming function contacts, and contacts for additional future functionality, among others.

Preferably, the self-test module 536 tests the internal circuitry and functionality of the remote device 452 for faults. The self-test module 536 indicates component failures by flashing indicator LEDs on the remote device user interface panel 390, as previously discussed. Other suitable methods to indicate self-test results can be used.

Preferably, the battery status module 540 displays the status and condition of a battery (not shown) in the remote device 452. The battery status module 540 may include a battery capacity display, such as a digital display; battery condition indicators, such as the previously discusses flashing indicator LEDs on the remote device user interface 390; and recharging rate indicator LEDs, among others. Other suitable displays or indicators can be used.

The timer module 542 can be implemented mechanically, with discrete electronics, with software, or by some combination thereof. Preferably, the timer module 542 is used for remote device features requiring elapsed time information. For example, the timer module 542 is a software implemented, countdown timer triggering a DISARM command to disarm the remote device 452 if the remote device 452 has been ARMED and not FIRED within a specified time period. Preferably, the timer module 542 serves as a backup to the timed disarm sequence in the controller device 450 previously discussed.

Preferably, the communications module 544 serves to enable safety communication between the remote device 452 and other system devices via a transmission medium. Preferably, the communications module 544 includes a 1-watt maximum power radio transceiver for transmission and reception of radio frequency signals in the kHz to MHz range. Any suitable power or frequency range can be used for the transceiver without departing materially from the present invention. Further, other suitable methods of communication can be used.

Preferably, the remote device user interface module 534 includes all user input into the remote device 452 not included in the remote device operating mode module 548, or remote device output mode module 546. This module includes functions such as turning a battery meter ON by depressing a momentary switch, among others.

Preferably, the remote device output module 546 serves as an interface for the user allowing method selection for initiating a remote detonation (such as shock tube or electric detonators), among others.

Preferably, the remote device operating mode module 548 serves as the user interface to select the operating mode of the remote device 452. The remote device operating mode module 548 may include NORMAL (signifying normal operation mode), and PROGRAMMING (signifying programming mode), among others. The NORMAL mode is preferably the default mode and is used for detonating explosives. The PROGRAMMING mode preferably allows the remote device 452 to be programmed with a semi-permanently assigned device identifier. Additional suitable modes, or suitable modification of the listed modes, can be included in the remote device operating mode module 548.

FIGS. 5A-O illustrate a method for remotely detonating explosives. Generally, in deploying a remote control blasting machine for remotely detonating explosives, preparatory steps are undertaken to ensure the operability of the device prior to deploying it in the field. Once the device is deployed in the field and coupled to the explosives, several safety checks are undertaken. The device in the field is armed and then fired. Upon completion, a remote control blasting machine is generally returned to a safe environment for storage until the next use.

In FIG. 5A, from a start block a method 600 proceeds to a set of method steps 602 between a continuation terminal (“Terminal A”) and an exit terminal (“Terminal B”). The set of method steps 602 prepares a remote firing system for operation in a mode desired by a user. This preparation includes steps to ensure that system devices are functional, deploying system devices in the field, and connecting remote devices to explosives in a safe manner.

From Terminal A (FIG. 5C), the method 600 proceeds to block 610 where a remote firing system's devices are powered ON. At block 612 each system device undergoes an automatic, internal, self-test operation. Self-testing verifies that the internal components of a device are operating within defined parameters. System devices failing the self-test are replaced. See block 614. The method 600 then continues to block 616 where the system devices' batteries are queried for remaining charge. Sufficient charge to operate the devices in the field for the estimated amount of time that will be required to place, arm, and detonate all explosives should be present. At block 618 system devices without sufficient charge are either recharged or replaced. The method 600 continues to another continuation terminal (“terminal A1”).

The processing steps between Terminals A and A1 can be accomplished either in parallel or serially. In parallel, all devices are contemporaneously powered ON, each then undergoes the self-test before each battery is checked for sufficient remaining charge, and system devices are then replaced or recharged, as needed. Serially, each device is powered ON, undergoes a self-test, the battery's remaining charge is checked, and the system device is replaced or recharged, as needed, before repeating the blocks for the next system device. Some blocks between Terminals A and A1 can readily be combined or further automated without departing from the present invention.

The processing steps described in FIGS. 5D-5F are preferably performed by a manufacturer of the remote firing system, a dealer or distributor of the manufacturer, or a service shop for the manufacturer. The user of the remote firing system needs not execute the processing steps described in FIGS. 5D-5F and these processing steps need not formed part of the use of the remote firing system in the field just prior to blasting activities. From terminal A1 (FIG. 5D), the method 600 enters a decision block 620 where a test is performed to determine whether a semi-permanent device identifier is to be assigned to a remote device. If the answer is YES (a semi-permanent device identification is to be assigned), the method 600 continues to another continuation terminal (“terminal A2”). If the answer is NO (a semi-permanent device identification is not to be assigned to a remote device), the method 600 continues to another terminal continuation terminal (terminal A3). From terminal A3, the method 600 proceeds to decision block 622 where it is determined if an electronic key is to be programmed. If an electronic key is to be programmed, the method continues to another continuation terminal (“terminal A4”). If an electronic key is not to be programmed, the method 600 continues to another continuation terminal (“terminal A5”).

From terminal A2 (FIG. 5E), the method 600 proceeds to block 624 where an appropriate master electronic key is coupled to the remote device to be programmed with a semi-permanent identification. At block 626, the information stored on the master electronic key causes the remote device to enter the PROGRAMMING mode. The information stored on the master electronic key causes the remote device in PROGRAMMING mode to assume a semi-permanent device identification. See block 628. The method 600 then continues to block 630 where the master electronic key is removed. Once the master electronic key has been removed, the remote device exits PROGRAMMING mode and is now programmed semi-permanently with a device identifier. Other suitable methods are possible to place the remote device into the PROGRAMMING mode to assign a device identifier. The method 600 then continues to terminal A1, where it loops back to decision block 620 and repeats the above-discussed processing steps. If additional devices are to be semi-permanently assigned device identifications, this loop may be continued. If additional devices are not to be semi-permanently assigned device identifiers, the method 600 exits the loop and proceeds to continuation terminal A3. From terminal A3, the method 600 proceeds to decision block 622, as previously discussed.

From terminal A4 (FIG. 5F), the method 600 proceeds to block 632 where an electronic key is coupled to a programming device. In one embodiment of the present invention the programming device includes a controller device. At block 634 where the programming device is placed in a PROGRAMMING mode. The present programming designation of the electronic key is then suitably indicated. See block 636. The method 600 continues to block 638 where a new programming designation is selected on the programming device. At block 640, the new programming designation data is stored on the electronic key and the key is decoupled from the programming device. The programming device is then taken out of PROGRAMMING mode. See block 640. The method 600 then proceeds to terminal A3 and loops back to decision block 622, where the above-discussed processing steps are repeated. If additional electronic keys are to be programmed, the loop is repeated. If no additional electronic keys are to be programmed, the method 600 continues to terminal A5.

From terminal A5 (FIG. 5G), the method 600 proceeds to block 670 where suitable electronic keys are placed in the remote devices according to a blast design. The blast design includes the placement of explosives and pieces of a remote firing system to effect a desired blasting result designed by a blasting engineer. A suitable electronic key indicates that an electronic key with a system identification, device identification, and indexed identifier is placed in each system device such that the blast engineer's plan can be executed. It is preferred that electronic keys be coupled with the remote devices for them to be able to communicate with the controller device. It is preferred that the controller device does not need an electronic key to do status queries but it is preferred that the electronic key be coupled with the controller device prior to arming or firing the remote devices. The method 600 proceeds to decision block 644 where a test is performed to determine whether a polling mode is used to aid the deployment of remote devices. If the answer is NO, (the polling mode is not being used for deployment), the method 600 continues to block 646 where system devices are deployed and suitably connected. The method 600 continues to another continuation terminal (“terminal A6”). If the answer is YES (the polling mode is used to aid in deployment), the method 600 continues to block 648 where a controller device is deployed and suitably coupled to devices such as an external antenna, any external interlock devices, or external power, among others. From block 648, the method 600 continues to block 650, where the polling mode is activated on the controller device. The polling mode causes the controller device to query the status of remote devices automatically and periodically. Remote devices are then deployed. See block 652. The method 600 then proceeds to another continuation terminal (“terminal A7”). Other suitable polling aids can be implemented.

From terminal A7 (FIG. 5H), the method 600 proceeds to decision block 654 where a test is performed to determine whether deployed remote devices receive the periodically transmitted status query from the controller device placed earlier at block 648 (see FIG. 5G). If the answer is NO (the deployed remote devices do not receive the periodic status query), the method 600 continues to block 658 where the deployed remote devices are suitably repositioned, replaced, or recharged. If the answer is YES (the deployed remote devices do receive the status query described at decision block 654), the method 600 continues to block 656 where another test is performed to determine whether the controller device is receiving status query replies from the deployed remote devices. If, at decision block 656, the answer is NO (the controller device is not receiving status query replies from deployed remote devices), the method 600 enters block 658 where the remote devices are suitably repositioned, replaced, or recharged. From block 658 the method 600 proceeds to another continuation terminal (“terminal A7”). If at decision block 656 the answer is YES (the controller device is receiving the status query replies), the method 600 continues to block 660 where the polling mode is deactivated. The method 600 then proceeds to another continuation terminal (“terminal A8”). Repositioning the controller device at block 658 can be a suitable alternative to repositioning remote devices.

Summarizing the processing steps between block 654 and block 656, the controller device automatically and periodically transmits a status query signal as remote devices are deployed. If the remote devices are receiving the periodic status query, they are in safety communication range. If they do not receive the status query, they are either defective, in the wrong location, or their battery has become depleted. The remote devices ought to be replaced, repositioned, or recharged. If the remote devices are receiving status queries, safety communication is confirmed by verifying that the controller device is receiving a reply to the status query. If the controller device is not receiving the reply to status query, safety communication is not established and the system devices ought to be repositioned, replaced, or recharged. Once the devices are in safety communication, the polling mode is deactivated.

When the polling mode is not used to aid in the deployment of system devices at decision block 644 (FIG. 5G), the method proceeds to terminal A6 (FIG. 5I). The method 600 proceeds to decision block 662 where a test is performed to determine whether the controller and remote devices are operating in safety communication. If the answer is NO (the devices are not operating in safety communication), the method 600 proceeds to terminal A8. If the answer is YES (the devices are operating in safety communication), the method 600 continues to block 664 where a status query operation is initiated at the controller device. This transmits a single status query to deployed remote devices. At decision block 666 a test is performed to determine whether the deployed remote devices return a status in response to the status query. If the answer is YES (the remote devices return a status to the controller), the method 600 proceeds to terminal A8. If the answer is NO (the remote devices do not return a status to the controller), the method 600 proceeds to block 668 where the non-answering remote devices are repositioned, replaced, or recharged. From block 668 the method 600 loops back to block 664 where a single status query is transmitted from the controller device. This loop continues until all deployed remote devices return a status to the controller, establishing safety communication.

From terminal A8 (FIG. 5J), the method 600 proceeds to block 672, a suitable electronic key is placed in the controller device. For blocks 670 and 672, a suitable electronic key indicates that an electronic key with a system identification, device identification, and indexed identifier is placed in each system device such that the blast engineer's plan can be executed. From block 672, the method 600 proceeds to Terminal B. The method 600 proceeds from Terminal B in block 602 (FIG. 5A) to Terminal C in block 604 (FIG. 5A).

From Terminal C (FIG. 5J), the method 600 proceeds to block 674 where at least one remote device is selected on the controller device. (Additional remote devices, or combinations of remote devices, can be selected on the controller device at block 674.) From block 674, the method 600 continues to Terminal D (FIG. 5J). From Terminal D (FIG. 5A) the method 600 proceeds to Terminal E (FIG. 5A) and then proceeds to Terminal E in block 606 (FIG. 5B).

From Terminal E (FIG. 5K), the method 600 proceeds to block 676 where the controller device transmits an ARM signal in response to receiving an ARM selection by the user. The method 600 then continues to block 678 where the controller device automatically transmits a status query to all remote devices after the ARM signal has been transmitted. At decision block 680, a test is performed to determine whether remote devices are armed. Arming is determined by the information contained in the reply to the status query. If the answer is YES (the remote devices have armed), the method 600 continues to another continuation terminal (“terminal E2”). If the answer is NO (the remote devices have not armed), the method 600 continues to block 682 where the control device indicates that the ARM signal was transmitted, but that a confirming signal (response to the automatic status query) was not received back from one or more of the remote devices. The method 600 then continues to another continuation terminal (“terminal E1”).

From terminal E1 (FIG. 5L), the method 600 proceeds to block 684 where the controller device automatically re-queries the status of the remote devices. At block 686, if the controller cannot establish a confirmed remote device status from the re-queries in block 684, the controller device indicates an assumed ARMED status. An assumed ARMED status indicates to a user that the controller device transmitted the ARM command, but that a reply was not received back from the remote device and that the secondary automatic attempts to confirm an ARMED status have failed. An assumed status also indicates that the remote device should be considered ARMED for any misfire procedure. From block 686, the method 600 continues to block 688 where either the ARM command is manually reissued or the shot is terminated for safety reasons. If the ARM command is to be reissued, blocks 680, 682, 684, and 686 will be repeated until successful arming or termination. From block 688, the method 600 proceeds to terminal E and loops back to the above-discussed processing steps. If the remote devices are ARMED at block 680, the method proceeds to terminal E2.

From terminal E2 (FIG. 5L), the method 600 continues to block 690 where an internal timer in each system device (both the remote devices and the controller device) begins a countdown to automatically DISARM all system devices. Preferably, if the countdown timer reaches the end of the countdown period without receiving a FIRE command, all system devices are automatically DISARMED as a safety precaution. From block 690 the method continues to terminal F. From terminal F (FIG. 5B), in block 606 (FIG. 5B), the method 600 proceeds to terminal G in block 608 (FIG. 5B).

From terminal G (FIG. 5M), the method 600 proceeds to decision block 692 where a test is performed to determine whether the countdown timer for disarming has elapsed in any device resulting in automatic DISARMING. If the answer is YES (the device countdown timer has elapsed), then the method 600 proceeds to continuation terminal E so that the selected remote devices can again be ARMED. If the answer is NO (the countdown timer has not elapsed), then the method 600 continues to block 694 where the controller device transmits a FIRE signal in response to receiving a fire selection from the user command. Preferably, the fire command is issued by simultaneously depressing, for at least one-half second (½ sec.), two FIRE buttons (as shown by buttons 384, 390). This long detent time and dual fire button arrangement increases safety by decreasing the chance of accidentally issuing a FIRE command. Other suitable methods for preventing accidental firing are possible. From block 694, the method 600 continues to block 696 where the controller device automatically transmits a status query to the remote devices after the FIRE signal has been transmitted. The method 600 then proceeds to decision block 698 where a test is performed to determine whether the remote devices have FIRED. The determination is based on information contained in the reply to the issued status query. If the answer is YES (the remote device has FIRED), the method 600 proceeds to another continuation terminal (“terminal G2”). If the answer is NO (the remote device has not FIRED), the method 600 proceeds to another continuation terminal (“terminal G1”). Both replies to the status query indicating failures to fire, and failures to reply to the status query, are considered as not FIRED conditions.

From terminal G1 (FIG. 5N), the method 600 proceeds to block 700. At block 700, the controller device indicates that a fire signal was transmitted, but that the confirming reply was either not received back from a remote device, or that the reply indicated an unsuccessful attempt to fire. At block 702 the controller automatically re-queries the status of the remote devices. If the controller device cannot confirm FIRING, the controller device indicates an assumed status. See block 704. The method 600 then continues to block 706 where a misfire procedure is initiated. The misfire procedure is not part of the present invention, but does determine what the user does next and is included herein for context. From block 706 the method 600 proceeds to another continuation terminal (“terminal G2”).

The method 600 permits the selection of one or more remote devices, therefore not all deployed devices may have been selected for the preceding ARM and FIRE method steps. From terminal G2 (FIG. 5O), the method 600 proceeds to decision block 708 where a test is performed to determine whether all deployed remote devices are FIRED. If the answer is NO (all deployed remote devices are not FIRED), the method 600 proceeds to terminal C, where additional remote devices can be selected, ARMED, and FIRED. If the answer is YES (all the deployed devices are FIRED), there are no more remote devices to FIRE and the method 600 proceeds to another continuation terminal (“terminal G3”). From terminal G3 (FIG. 5O), the method 600 proceeds to block 710 where the electronic keys are decoupled from all system devices. When system devices are decoupled from electronic keys, the devices become inoperable, yet remain ON. From block 710 the method 600 continues to block 712 where all system devices are powered OFF, the remote firing system is removed from the field, and the remote firing system is stored. From block 712 the method 600 continues to terminal H. From terminal H (FIG. 5B) in block 608 (FIG. 5B), the method 600 is completed and proceeds to the finish block (FIG. 5B.)

While the preferred embodiment of the invention has been illustrated and described, it will be appreciated that various changes can be made therein without departing from the spirit and scope of the invention. 

1. A remote firing system comprising: a set of remote devices, each remote device being capable of communicating a safety data structure that includes a system identifier for identifying the remote firing system from other remote firing systems and a device identifier for identifying a remote device from other remote devices; and a controller device for causing the set of remote devices to trigger detonators, the controller device being capable of selecting a subset of the set of remote devices for triggering detonators and further being capable of communicating the safety data structure that includes a system identifier for identifying the remote firing system from other remote firing systems and device identifiers for identifying the subset of remote devices to control.
 2. The remote firing system of claim 1, wherein each remote device includes a shock tube detonator initiation system and an electric detonator initiating system for detonating explosives.
 3. The remote firing system of claim 1, wherein each remote device operates when a compatible remote electronic key is coupled to the remote device and wherein the controller device operates normally when a compatible controller electronic key is coupled to the controller device.
 4. The remote firing system of claim 1, wherein the controller device is capable of causing periodic verification of safety communication among the controller device and the subset of the set of remote devices.
 5. The remote firing system of claim 1, wherein each remote device is capable of being semi-permanently programmed to take on a temporary identity which is removed upon the removal of an electronic key.
 6. A controller device, comprising: a set of selection and information panels that correspond with a set of remote devices, a subset of selection and information panels being selectable to cause a corresponding subset of remote devices to be selected for detonating explosives; and a communication module for transmitting and receiving safety communication, the communication module being capable of communicating with the subset of remote devices to indicate their selection for detonating explosives by the controller device.
 7. The controller device of claim 6, further comprising dual fire panels that include dual fire switches, the dual fire switches being selectable together to cause the communication module to transmit a fire command to the subset of remote devices.
 8. The controller device of claim 6, wherein each selection and information panel of the set of selection and information panels includes a ready indicator to indicate that a corresponding remote device is ready for operation, an armed indicator to indicate that the corresponding remote device is armed for detonating explosives, a battery indicator to indicate the condition of the battery of the corresponding remote device, and a selected indicator to indicate whether the corresponding remote device is selected.
 9. The controller device of claim 6, further comprising a status panel being selectable to query the subset of remote devices for their status, the status of the subset of remote devices being presentable on the subset of the selection and information panels.
 10. The controller device of claim 6, further comprising an electronic key port that is adapted to receive an electronic key to cause the controller device to operate.
 11. A remote device comprising: a communication module for transmitting and receiving a safety data structure that contains a system identifier for identifying a remote firing system that comprises the remote device and a device identifier for identifying the remote device; and a switch for selecting either shock-tube detonator initiation or electric detonator initiation.
 12. The remote device of claim 11, further comprising an indicator panel for indicating whether shock tube initiation is ready or armed.
 13. The remote device of claim 12, further comprising an indicator panel for indicating whether electric detonator initiation is ready or armed.
 14. The remote device of claim 11, further comprising an electronic key port that is adapted to receive an electronic key to cause the remote device to operate.
 15. The remote device of claim 11, further comprising a programming port to program the remote device.
 16. A method for remotely detonating explosives, comprising: selecting a subset of a set of selection and information panels on a controller device to cause a corresponding subset of remote devices to be selected for detonating explosives; issuing an arming command by the controller device to the subset of remote devices to cause the subset of remote devices to prepare for detonation; and issuing a firing command by the controller device to the subset of remote devices by simultaneously selecting dual fire switches together on the controller device to cause the subset of remote devices to detonate explosives.
 17. The method of claim 16, further comprising inserting electronic keys to the controller device and the set of remote devices prior to the act of selecting the subset of the set of selection and information panels so as to cause the controller device and the set of remote devices to operate.
 18. The method of claim 16, further comprising activating a polling mode to verify safety communication among the set of remote devices and the controller device, the polling mode causing the controller device to issue status query command to the set of the remote devices and the subset of remote devices responding to the status query command.
 19. The method of claim 16, wherein after the act of issuing the arming command the controller device automatically issues a status query command to verify the arming of the subset of the remote devices, each member of the subset of the set of selection and information panels indicating whether a corresponding member of the subset of the remote devices is armed.
 20. The method of claim 16, wherein after the act of issuing the firing command the controller device automatically issues a status query command to verify the firing of the subset of the remote devices, each member of the subset of the set of selection and information panels indicating whether a corresponding member of the subset of the remote devices has fired. 